JavaScript WeakRef Observer uzorak: Izgradnja sustava događaja svjesnih memorije

U svijetu modernog web razvoja, Jednostranične Aplikacije (SPA) postale su standard za stvaranje dinamičnih i responzivnih korisničkih iskustava. Ove aplikacije često rade dulje vrijeme, upravljaju složenim stanjem i obrađuju bezbrojne korisničke interakcije. Međutim, ova dugotrajnost dolazi sa skrivenom cijenom: povećanim rizikom od curenja memorije. Curenje memorije, gdje aplikacija zadržava memoriju koja joj više ne treba, može s vremenom smanjiti performanse, što dovodi do sporosti, rušenja preglednika i lošeg korisničkog iskustva. Jedan od najčešćih izvora ovih curenja leži u temeljnom dizajnerskom uzorku: uzorku Promatrač (Observer).

Uzorak Promatrač (Observer) je kamen temeljac arhitekture vođene događajima, omogućujući objektima (promatračima) da se pretplate i primaju ažuriranja od centralnog objekta (subjekta). Elegantan je, jednostavan i nevjerojatno koristan. Ali njegova klasična implementacija ima kritičnu manu: subjekt održava jake reference na svoje promatrače. Ako promatrač više nije potreban ostatku aplikacije, ali programer zaboravi eksplicitno odjaviti pretplatu s subjekta, nikada neće biti sakupljen smećem. Ostaje zarobljen u memoriji, duh koji proganja performanse vaše aplikacije.

Ovdje moderni JavaScript, sa svojim značajkama ECMAScript 2021 (ES12), pruža moćno rješenje. Koristeći WeakRef i FinalizationRegistry, možemo izgraditi uzorak Promatrača svjesnog memorije koji se automatski čisti, sprječavajući ova uobičajena curenja. Ovaj članak je dubinski uvid u ovu naprednu tehniku. Istražit ćemo problem, razumjeti alate, izgraditi robusnu implementaciju od nule i raspraviti kada i gdje bi se ovaj moćni uzorak trebao primijeniti u vašim globalnim aplikacijama.

Razumijevanje temeljnog problema: Klasični uzorak promatrača i njegov memorijski otisak

Prije nego što možemo cijeniti rješenje, moramo u potpunosti shvatiti problem. Uzorak Promatrač, poznat i kao uzorak Izdavač-Pretplatnik, dizajniran je za razdvajanje komponenti. Subjekt (ili Izdavač) održava popis svojih ovisnika, nazvanih Promatrači (ili Pretplatnici). Kada se stanje Subjekta promijeni, automatski obavještava sve svoje Promatrače, obično pozivanjem specifične metode na njima, kao što je update().

Pogledajmo jednostavnu, klasičnu implementaciju u JavaScriptu.

Jednostavna implementacija subjekta

Ovdje je osnovna klasa Subjekta. Ima metode za pretplatu, odjavu pretplate i obavještavanje promatrača.

class ClassicSubject {

  constructor() {

    this.observers = [];

  }

 

  subscribe(observer) {

    this.observers.push(observer);

    console.log(`${observer.name} has subscribed.`);

  }

 

  unsubscribe(observer) {

    this.observers = this.observers.filter(obs => obs !== observer);

    console.log(`${observer.name} has unsubscribed.`);

  }

 

  notify(data) {

    console.log('Notifying observers...');

    this.observers.forEach(observer => observer.update(data));

  }

}

A evo i jednostavne klase Promatrača koja se može pretplatiti na Subjekt.

class Observer {

  constructor(name) {

    this.name = name;

  }

 

  update(data) {

    console.log(`${this.name} received data: ${data}`);

  }

}

Skrivena opasnost: Preostale reference

Ova implementacija savršeno funkcionira sve dok marljivo upravljamo životnim ciklusom naših promatrača. Problem nastaje kada to ne činimo. Razmotrimo uobičajeni scenarij u velikoj aplikaciji: dugovječnu globalnu pohranu podataka (Subjekt) i privremenu UI komponentu (Promatrač) koja prikazuje neke od tih podataka.

Simulirajmo ovaj scenarij:

const dataStore = new ClassicSubject();

 

function manageUIComponent() {

  let chartComponent = new Observer('ChartComponent');

  dataStore.subscribe(chartComponent);

 

  // The component does its job...

 

  // Now, the user navigates away, and the component is no longer needed.

  // A developer might forget to add the cleanup code:

  // dataStore.unsubscribe(chartComponent);

 

  chartComponent = null; // We release our reference to the component.

}

 

manageUIComponent();

 

// Later in the application lifecycle...

dataStore.notify('New data available!');

U funkciji `manageUIComponent` stvaramo `chartComponent` i pretplaćujemo je na naš `dataStore`. Kasnije, postavljamo `chartComponent` na `null`, signalizirajući da smo završili s njom. Očekujemo da će JavaScript sakupljač smeća (GC) vidjeti da nema više referenci na ovaj objekt i povratiti njegovu memoriju.

Ali postoji još jedna referenca! Niz `dataStore.observers` i dalje drži izravnu, jaku referencu na objekt `chartComponent`. Zbog ove pojedinačne preostale reference, sakupljač smeća ne može povratiti memoriju. Objekt `chartComponent` i svi resursi koje drži, ostat će u memoriji tijekom cijelog životnog vijeka `dataStore`. Ako se to događa više puta — na primjer, svaki put kada korisnik otvori i zatvori modalni prozor — korištenje memorije aplikacije će se neograničeno povećavati. Ovo je klasično curenje memorije.

Nova nada: Predstavljamo WeakRef i FinalizationRegistry

ECMAScript 2021 uveo je dvije nove značajke posebno dizajnirane za rješavanje ovakvih izazova upravljanja memorijom: `WeakRef` i `FinalizationRegistry`. To su napredni alati i treba ih koristiti s oprezom, ali za naš problem uzorka Promatrača, oni su savršeno rješenje.

Što je WeakRef?

Objekt `WeakRef` drži slabu referencu na drugi objekt, nazvan svojom metom. Ključna razlika između slabe reference i normalne (jake) reference je sljedeća: slaba referenca ne sprječava sakupljanje smeća svog ciljnog objekta.

Ako su jedine reference na objekt slabe reference, JavaScript motor slobodno uništava objekt i oslobađa njegovu memoriju. To je upravo ono što nam je potrebno za rješavanje našeg problema Promatrača.

Da biste koristili `WeakRef`, stvarate njegovu instancu, prosljeđujući ciljni objekt konstruktoru. Za pristup ciljnom objektu kasnije, koristite metodu `deref()`.

let targetObject = { id: 42 };

const weakRefToObject = new WeakRef(targetObject);

 

// To access the object:

const retrievedObject = weakRefToObject.deref();

 

if (retrievedObject) {

  console.log(`Object is still alive: ${retrievedObject.id}`); // Output: Object is still alive: 42

} else {

  console.log('Object has been garbage collected.');

}

Ključni dio je da `deref()` može vratiti `undefined`. To se događa ako je `targetObject` sakupljen smećem jer više ne postoje jake reference na njega. Ovo ponašanje je temelj našeg uzorka Promatrača svjesnog memorije.

Što je FinalizationRegistry?

Dok `WeakRef` omogućuje prikupljanje objekta, ne pruža nam čist način da znamo kada je prikupljen. Mogli bismo povremeno provjeravati `deref()` i uklanjati `undefined` rezultate s našeg popisa promatrača, ali to je neučinkovito. Ovdje dolazi `FinalizationRegistry`.

A `FinalizationRegistry` vam omogućuje registraciju funkcije povratnog poziva koja će biti pozvana nakon što je registrirani objekt sakupljen smećem. To je mehanizam za post-mortem čišćenje.

Evo kako to funkcionira:

1. Izradite registar s povratnim pozivom za čišćenje.
2. Registrirajte (`register()`) objekt u registru. Također možete navesti `heldValue`, što je dio podataka koji će biti proslijeđen vašem povratnom pozivu kada se objekt prikupi. Ova `heldValue` ne smije biti izravna referenca na sam objekt, jer bi to porazilo svrhu!

// 1. Create the registry with a cleanup callback

const registry = new FinalizationRegistry(heldValue => {

  console.log(`An object has been garbage collected. Cleanup token: ${heldValue}`);

});

 

(function() {

  let objectToTrack = { name: 'Temporary Data' };

  let cleanupToken = 'temp-data-123';

 

  // 2. Register the object and provide a token for cleanup

  registry.register(objectToTrack, cleanupToken);

 

  // objectToTrack goes out of scope here

})();

 

// At some point in the future, after the GC runs, the console will log:

// "An object has been garbage collected. Cleanup token: temp-data-123"

Važna upozorenja i najbolje prakse

Prije nego što zaronimo u implementaciju, ključno je razumjeti prirodu ovih alata. Ponašanje sakupljača smeća uvelike ovisi o implementaciji i nije determinističko. To znači:

• Ne možete predvidjeti kada će objekt biti prikupljen. To mogu biti sekunde, minute ili čak dulje nakon što postane nedostupan.
• Ne možete se osloniti na povratne pozive `FinalizationRegistry` da će se izvršiti pravovremeno ili predvidivo. Oni su za čišćenje, a ne za kritičnu logiku aplikacije.
• Prekomjerno korištenje `WeakRef` i `FinalizationRegistry` može otežati razumijevanje koda. Uvijek preferirajte jednostavnija rješenja (poput eksplicitnih `unsubscribe` poziva) ako su životni ciklusi objekata jasni i upravljivi.

Ove značajke najbolje odgovaraju situacijama u kojima je životni ciklus jednog objekta (promatrača) istinski neovisan i nepoznat drugom objektu (subjektu).

Izgradnja uzorka `WeakRefObserver`: Korak po korak implementacija

Sada, kombinirajmo `WeakRef` i `FinalizationRegistry` kako bismo izgradili memorijski sigurnu klasu `WeakRefSubject`.

Korak 1: Struktura klase `WeakRefSubject`

Naša nova klasa će pohranjivati `WeakRef` objekte za promatrače umjesto izravnih referenci. Također će imati `FinalizationRegistry` za rukovanje automatskim čišćenjem popisa promatrača.

class WeakRefSubject {

  constructor() {

    this.observers = new Set(); // Using a Set for easier removal

 

    // The finalizer callback. It receives the held value we provide during registration.

    // In our case, the held value will be the WeakRef instance itself.

    this.cleanupRegistry = new FinalizationRegistry(weakRefObserver => {

      console.log('Finalizer: An observer has been garbage collected. Cleaning up...');

      this.observers.delete(weakRefObserver);

    });

  }

}

Koristimo `Set` umjesto `Array` za naš popis promatrača. To je zato što je brisanje stavke iz `Set`-a mnogo učinkovitije (prosječna vremenska složenost O(1)) nego filtriranje `Array`-a (O(n)), što će biti korisno u našoj logici čišćenja.

Korak 2: Metoda `subscribe`

Metoda `subscribe` je mjesto gdje počinje magija. Kada se promatrač pretplati, mi ćemo:

1. Stvoriti `WeakRef` koji pokazuje na promatrača.
2. Dodati ovaj `WeakRef` u naš set `observers`.
3. Registrirati originalni objekt promatrača s našim `FinalizationRegistry`, koristeći novostvoreni `WeakRef` kao `heldValue`.

// Inside the WeakRefSubject class...

subscribe(observer) {

  // Check if an observer with this reference already exists

  for (const ref of this.observers) {

    if (ref.deref() === observer) {

      console.warn('Observer already subscribed.');

      return;

    }

  }

 

  const weakRefObserver = new WeakRef(observer);

  this.observers.add(weakRefObserver);

 

  // Register the original observer object. When it's collected,

  // the finalizer will be called with `weakRefObserver` as the argument.

  this.cleanupRegistry.register(observer, weakRefObserver);

 

  console.log('An observer has subscribed.');

}

Ova postavka stvara pametnu petlju: subjekt drži slabu referencu na promatrača. Registar drži jaku referencu na promatrača (interno) dok se ne sakuplja smećem. Nakon što je sakupljen, povratni poziv registra se aktivira s instancom slabe reference, koju zatim možemo koristiti za čišćenje našeg skupa `observers`.

Korak 3: Metoda `unsubscribe`

Čak i uz automatsko čišćenje, trebali bismo i dalje pružiti ručnu metodu `unsubscribe` za slučajeve kada je potrebno determinističko uklanjanje. Ova metoda će morati pronaći ispravan `WeakRef` u našem setu dereferenciranjem svakog i usporedbom s promatračem kojeg želimo ukloniti.

// Inside the WeakRefSubject class...

unsubscribe(observer) {

  let refToRemove = null;

  for (const weakRef of this.observers) {

    if (weakRef.deref() === observer) {

      refToRemove = weakRef;

      break;

    }

  }

 

  if (refToRemove) {

    this.observers.delete(refToRemove);

    // IMPORTANT: We must also unregister from the finalizer

    // to prevent the callback from running unnecessarily later.

    this.cleanupRegistry.unregister(observer);

    console.log('An observer has unsubscribed manually.');

  }

}

Korak 4: Metoda `notify`

Metoda `notify` iterira kroz naš set `WeakRef` objekata. Za svaki, pokušava ga `deref()` kako bi dobila stvarni objekt promatrača. Ako `deref()` uspije, to znači da je promatrač još uvijek živ i možemo pozvati njegovu `update` metodu. Ako vrati `undefined`, promatrač je sakupljen, i možemo ga jednostavno ignorirati. `FinalizationRegistry` će na kraju ukloniti njegov `WeakRef` iz seta.

// Inside the WeakRefSubject class...

notify(data) {

  console.log('Notifying observers...');

  for (const weakRefObserver of this.observers) {

    const observer = weakRefObserver.deref();

    if (observer) {

      // The observer is still alive

      observer.update(data);

    } else {

      // The observer has been garbage collected.

      // The FinalizationRegistry will handle removing this weakRef from the set.

      console.log('Found a dead observer reference during notification.');

    }

  }

}

Sve zajedno: Praktičan primjer

Vratimo se na naš scenarij UI komponente, ali ovaj put koristeći naš novi `WeakRefSubject`. Za jednostavnost ćemo koristiti istu klasu `Observer` kao i prije.

// The same simple Observer class

class Observer {

  constructor(name) {

    this.name = name;

  }

  update(data) {

    console.log(`${this.name} received data: ${data}`);

  }

}

Sada, stvorimo globalnu uslugu podataka i simulirajmo privremeni UI widget.

const globalDataService = new WeakRefSubject();

function createAndDestroyWidget() {

  console.log('--- Creating and subscribing new widget ---');

  let chartWidget = new Observer('RealTimeChartWidget');

  globalDataService.subscribe(chartWidget);

 

  // The widget is now active and will receive notifications

  globalDataService.notify({ price: 100 });

 

  console.log('--- Destroying widget (releasing our reference) ---');

  // We are done with the widget. We set our reference to null.

  // We DO NOT need to call unsubscribe().

  chartWidget = null;

}

createAndDestroyWidget();

console.log('--- After widget destruction, before garbage collection ---');

globalDataService.notify({ price: 105 });

Nakon pokretanja `createAndDestroyWidget()`, objekt `chartWidget` sada je referenciran samo pomoću `WeakRef` unutar naše `globalDataService`. Budući da je ovo slaba referenca, objekt je sada podoban za sakupljanje smeća.

Kada se sakupljač smeća eventualno pokrene (što ne možemo predvidjeti), dogodit će se dvije stvari:

1. Objekt `chartWidget` bit će uklonjen iz memorije.
2. Povratni poziv našeg `FinalizationRegistry`-a bit će aktiviran, što će zatim ukloniti sada mrtvu `WeakRef` iz seta `globalDataService.observers`.

Ako ponovno pozovemo `notify` nakon što se sakupljač smeća pokrene, poziv `deref()` vratit će `undefined`, mrtvi promatrač će biti preskočen, a aplikacija nastavlja raditi učinkovito bez ikakvih curenja memorije. Uspješno smo razdvojili životni ciklus promatrača od subjekta.

Kada koristiti (i kada izbjegavati) uzorak `WeakRefObserver`

Ovaj uzorak je moćan, ali nije srebrni metak. Uvodi složenost i oslanja se na nedeterminističko ponašanje. Ključno je znati kada je pravi alat za posao.

Idealni slučajevi upotrebe

• Dugovječni subjekti i kratkovječni promatrači: Ovo je kanonski slučaj upotrebe. Globalna usluga, pohrana podataka ili predmemorija (subjekt) koja postoji tijekom cijelog životnog vijeka aplikacije, dok se brojne UI komponente, privremeni radnici ili dodaci (promatrači) često stvaraju i uništavaju.
• Mehanizmi predmemoriranja: Zamislite predmemoriju koja mapira složeni objekt na neki izračunati rezultat. Možete koristiti `WeakRef` za ključni objekt. Ako je originalni objekt sakupljen smećem iz ostatka aplikacije, `FinalizationRegistry` može automatski očistiti odgovarajući unos u vašoj predmemoriji, sprječavajući napuhavanje memorije.
• Arhitekture dodataka i proširenja: Ako gradite jezgreni sustav koji omogućuje modulima trećih strana da se pretplate na događaje, korištenje `WeakRefObserver`-a dodaje sloj otpornosti. Sprječava da loše napisan dodatak koji zaboravi odjaviti pretplatu uzrokuje curenje memorije u vašoj osnovnoj aplikaciji.
• Mapiranje podataka na DOM elemente: U scenarijima bez deklarativnog okvira, možda ćete htjeti povezati neke podatke s DOM elementom. Ako to pohranite u mapu s DOM elementom kao ključem, možete stvoriti curenje memorije ako se element ukloni iz DOM-a, ali je i dalje u vašoj mapi. `WeakMap` je bolji izbor ovdje, ali princip je isti: životni ciklus podataka trebao bi biti vezan za životni ciklus elementa, a ne obrnuto.

Kada se držati klasičnog promatrača

• Usko povezani životni ciklusi: Ako se subjekt i njegovi promatrači uvijek stvaraju i uništavaju zajedno ili unutar istog opsega, opterećenje i složenost `WeakRef`-a su nepotrebni. Jednostavan, eksplicitan poziv `unsubscribe()` je čitljiviji i predvidljiviji.
• Kritične putanje performansi: Metoda `deref()` ima mali, ali ne-nulti trošak performansi. Ako obavještavate tisuće promatrača stotine puta u sekundi (npr. u petlji igre ili vizualizaciji podataka visoke frekvencije), klasična implementacija s izravnim referencama bit će brža.
• Jednostavne aplikacije i skripte: Za manje aplikacije ili skripte gdje je životni vijek aplikacije kratak i upravljanje memorijom nije značajna briga, klasični uzorak je jednostavniji za implementaciju i razumijevanje. Nemojte dodavati složenost tamo gdje nije potrebna.
• Kada je potrebno determinističko čišćenje: Ako trebate izvršiti radnju u točno određenom trenutku kada se promatrač odvoji (npr. ažuriranje brojača, oslobađanje specifičnog hardverskog resursa), morate koristiti ručnu metodu `unsubscribe()`. Nedeterministička priroda `FinalizationRegistry`-a čini ga neprikladnim za logiku koja se mora izvršiti predvidljivo.

Šire implikacije za softversku arhitekturu

Uvođenje slabih referenci u visokorazinski jezik poput JavaScripta signalizira sazrijevanje platforme. Omogućuje programerima da izgrade sofisticiranije i otpornije sustave, posebno za dugotrajne aplikacije. Ovaj uzorak potiče pomak u arhitektonskom razmišljanju:

• Prava razdvojenost: Omogućuje razinu razdvojenosti koja nadilazi samo sučelje. Sada možemo razdvojiti same životne cikluse komponenti. Subjekt više ne treba znati ništa o tome kada se njegovi promatrači stvaraju ili uništavaju.
• Otpornost po dizajnu: Pomaže u izgradnji sustava koji su otporniji na programerske pogreške. Zaboravljeni poziv `unsubscribe()` uobičajena je pogreška koju je teško pratiti. Ovaj uzorak ublažava cijelu klasu takvih pogrešaka.
• Omogućavanje autora okvira i biblioteka: Za one koji grade okvire, biblioteke ili platforme za druge programere, ovi su alati neprocjenjivi. Omogućuju stvaranje robusnih API-ja koji su manje osjetljivi na zlouporabu od strane korisnika biblioteke, što dovodi do stabilnijih aplikacija općenito.

Zaključak: Moćan alat za modernog JavaScript programera

Klasični uzorak Promatrača je temeljni gradivni blok softverskog dizajna, ali njegovo oslanjanje na jake reference dugo je bilo izvor suptilnih i frustrirajućih curenja memorije u JavaScript aplikacijama. Dolaskom `WeakRef` i `FinalizationRegistry` u ES2021, sada imamo alate za prevladavanje ovog ograničenja.

Krenuli smo od razumijevanja temeljnog problema preostalih referenci do izgradnje potpune, memorijski svjesne klase `WeakRefSubject` od temelja. Vidjeli smo kako `WeakRef` omogućuje sakupljanje smeća objekata čak i kada su 'promatrani', i kako `FinalizationRegistry` pruža mehanizam automatskog čišćenja kako bi naš popis promatrača ostao besprijekoran.

Međutim, s velikom moći dolazi i velika odgovornost. To su napredne značajke čija nedeterministička priroda zahtijeva pažljivo razmatranje. One nisu zamjena za dobar dizajn aplikacije i marljivo upravljanje životnim ciklusom. Ali kada se primijeni na prave probleme — kao što je upravljanje komunikacijom između dugovječnih usluga i efemernih komponenti — uzorak WeakRef Observer iznimno je moćna tehnika. Svladavanjem toga, možete pisati robusnije, učinkovitije i skalabilnije JavaScript aplikacije, spremne za ispunjavanje zahtjeva modernog, dinamičnog weba.